The present disclosure relates in general to web applications, and in particular to techniques for optimizing scrolling performance in a web-based data grid.
With the ubiquity of web browsers and broadband Internet access, many types of software that previously existed only as traditional desktop applications are now available in web application form. Generally speaking, a web application is a software application that includes a server component and a client component, where the server component is hosted on a remote server (e.g., a web and/or application server) and the client component is rendered/executed in a common web browser. Examples of popular web applications include email, calendar, and so on.
Certain types of web applications, such as spreadsheets and other kinds of business applications, make use of a data grid for receiving and/or presenting data to a user. As used herein, a data grid is a UI component comprising a group of data cells that are arranged in a tabular or other similar format. Each cell in the grid can include editable or non-editable data. Data grids can be used to represent a number of different types of tabular data structures, such as flat tables, summary (e.g., pivot) tables, and the like.
In some cases, the size of a data set being presented in a web-based data grid can be so large that it cannot be viewed, in its entirety, within the visible window (i.e., viewport) allocated to the grid by a client web browser. In these cases, users of the data grid generally need to scroll through the grid in order to see all of the data. To conserve client side memory and to improve initial load time in these scenarios, some web applications implement a technique known as “virtualized scrolling.” With this technique, only a portion of the data set (e.g., the data visible in the viewport) is retrieved from the server and stored by the client component. As a user scrolls through the data grid (thus changing the portion of the data set visible in the viewport), new blocks of data are fetched from the server by the client component to fill/refresh the viewport, and data that is no longer visible is discarded.
Web applications that implement virtualized scrolling typically maintain a single block size parameter that indicates the amount of data to fetch from the server by the client component when a user scrolls through the data grid. One issue with this approach is that a single block size is generally not optimal for all types of scroll events. For instance, a smaller block size might be preferable for “short scrolls”—i.e., scroll events where the user scrolls a few rows or columns, such that only a portion of the viewport needs to be filled with new data from the server. In contrast, a larger block size might be preferable for “long scrolls”—i.e., scroll events where the user scrolls a long distance from the original grid position, such that the entire viewport needs to be filled with new data from the server.
For example, consider a scenario where the user performs a long scroll. In response to the scroll event, the client component will request and receive a new data block, per the block size parameter, from the server. However, if the received data block is too small (e.g., not large enough to fill the entire viewport), the client component will need to fetch additional data blocks from the server in order to fill the remainder of the viewport. These multiple roundtrips between the client and server can be time-consuming and give the impression that the application is unresponsive to the user's scrolling commands.